openmetadata-service/src/main/java/org/openmetadata/service/jdbi3/EntityRepository.java:4338

• Same concern as the by-id PATCH path: loading the base with PATCH_ORIGINAL_INCLUDES for every PATCH can cause PATCHes that don't touch owners/experts/reviewers/followers to fail when one of those relations points at a soft-deleted user, because later validation resolves owners with Include.NON_DELETED and throws.

Gate PATCH_ORIGINAL_INCLUDES behind whether the patch actually modifies one of those fields; otherwise keep NON_DELETED behavior to avoid new failures.

    // Get only the fields relevant to this patch operation
    T original;
    try (var ignored = phase("patchLoadOriginalByName")) {
      original = getByName(null, fqn, patchFields, PATCH_ORIGINAL_INCLUDES, false);

openmetadata-service/src/main/java/org/openmetadata/service/jdbi3/EntityRepository.java:445

• Changing PATCH to load the original with owners/experts/reviewers/followers = Include.ALL fixes clients that diff against an include=all representation, but it can break clients that build a positional JSON Patch from a NON_DELETED owner array (they will now apply indices against a longer server-side base and can remove the wrong owner).

This is not just theoretical: the UI’s updateEntityField uses fast-json-patch positional diffs, and some entity GETs explicitly request includeRelations: 'owners:non-deleted,…' (e.g. openmetadata-ui/src/main/resources/ui/src/rest/tableAPI.ts:65-77). In a scenario where a soft-deleted owner sorts before an active owner, a client removing /owners/0 from its filtered array would cause the server to remove the soft-deleted owner instead, leaving the intended active owner unchanged.

Consider a contract-level fix: e.g. allow PATCH to accept an includeRelations/relationIncludes parameter (or header) so the client can declare which representation it diffed against, or switch the UI to a non-positional update for these arrays (whole-array replace / ID-based operations).

  // A PATCH's base ("original") must resolve user references the same way the client did when it
  // computed the diff. Detail pages fetch with include=all, so a soft-deleted owner (or expert,
  // reviewer, follower) is in the client's base. Loading the server base with NON_DELETED drops it
  // and shrinks the array, so a positional JSON-Patch op goes out of range ("array item index out
  // of range") and the dangling relationship can never be removed. Resolve these relations with ALL
  // for the patch base; the entity itself still loads NON_DELETED so a soft-deleted entity is not
  // patched through this path. See issue #30117.
  private static final RelationIncludes PATCH_ORIGINAL_INCLUDES =
      new RelationIncludes(
          NON_DELETED,
          Map.of(
              FIELD_OWNERS, ALL,
              FIELD_EXPERTS, ALL,
              FIELD_REVIEWERS, ALL,
              FIELD_FOLLOWERS, ALL));

openmetadata-service/src/main/java/org/openmetadata/service/jdbi3/EntityRepository.java:443

• The new PATCH_ORIGINAL_INCLUDES block comment has broken wrapping (standalone "a", "entity", "latent" lines), which makes it harder to read and looks like an accidental formatter artifact. Please reflow it into complete sentences on each line.

  // A PATCH's base ("original") must resolve OWNER references the same way the client diffed
  // against. Detail pages fetch with include=all, so a soft-deleted owner is in the client's base;
  // a
  // NON_DELETED server base drops it and shrinks the array, so a positional JSON-Patch op goes out
  // of range ("array item index out of range") and the dangling ownership can never be removed.

openmetadata-integration-tests/src/test/java/org/openmetadata/it/tests/BaseEntityIT.java:868

• This test uses Assumptions.assumeTrue(...) to verify conditions that should be deterministic (owners were just assigned and fetched with include=all). If this ever fails it indicates a real regression and should fail the test rather than silently skip it.

    JsonNode ownersBefore = ownersWithIncludeAll(entityPath);
    int doomedIndex = indexOfOwner(ownersBefore, doomedOwner.getId());
    Assumptions.assumeTrue(
        indexOfOwner(ownersBefore, activeOwner.getId()) >= 0 && doomedIndex >= 0,
        "both explicit owners must be assigned and the soft-deleted one surfaced by include=all");

openmetadata-ui/src/main/resources/ui/src/rest/testAPI.ts:421

• The new default includeRelations + inline comment implements a UI-side workaround by filtering soft-deleted owners out of the GET response (to match a NON_DELETED PATCH base). This conflicts with the PR title/description, which describe a server-side fix that keeps soft-deleted owners in the PATCH base so they can be removed. Please reconcile by either (a) including the described backend change and adjusting this default accordingly, or (b) updating the PR title/description to reflect that this change intentionally hides soft-deleted owners instead of preserving them for removal.

      // Resolve owners/experts as non-deleted (consistent with data-asset detail pages), so a
      // soft-deleted owner is not surfaced and the owner-edit diff stays aligned with the server's
      // NON_DELETED PATCH base - otherwise a positional patch throws "array item index out of
      // range". See issue #30117.
      params: {

openmetadata-ui/src/main/resources/ui/src/rest/testAPI.test.ts:886

• This test case bakes in the new contract that getTestSuiteByName hides soft-deleted owners by default. That seems inconsistent with the PR title/description (server-side PATCH base fix to keep soft-deleted owners present so they can be removed). Please confirm the intended end-state and adjust either the implementation/tests or the PR metadata accordingly.

      it('should default owners/experts to non-deleted so soft-deleted owners stay hidden (issue #30117)', async () => {

openmetadata-ui/src/main/resources/ui/src/rest/testAPI.test.ts:890

• These tests only assert that the client sends an includeRelations query param. However, the current backend GET /dataQuality/testSuites/name/{name} endpoint does not accept includeRelations, so this test can pass even if the runtime behavior (hiding soft-deleted owners and avoiding the PATCH crash) is unchanged.

Consider adding coverage that exercises the end-to-end behavior after the backend endpoint supports includeRelations, or adjust the fix to use an endpoint/query param combination that is actually honored by the server today.

      it('should default owners/experts to non-deleted so soft-deleted owners stay hidden (issue #30117)', async () => {
        const mockGet = jest.fn().mockResolvedValue({ data: mockTestSuite });
        jest.mock('./index', () => ({
          __esModule: true,
          default: {

openmetadata-service/src/main/java/org/openmetadata/service/resources/dqtests/TestSuiteResource.java:439

• The PR description states "No backend change", but this change updates the TestSuite REST API surface by adding/forwarding the includeRelations query parameter on the GET /dataQuality/testSuites/name/{name} endpoint (and adds an IT to cover it). Please update the PR description to reflect that there is a (backward-compatible) backend wiring/API-doc change, so reviewers/release notes don’t miss it.

                      + "If not specified for a field, uses the entity's include value.",
              schema = @Schema(type = "string", example = "owners:non-deleted,followers:all"))
          @QueryParam("includeRelations")
          String includeRelations) {
    return getByNameInternal(